Patrick Hagerty wrote:
> Well, just to test exactly that theory, I used it in several applications to 
> make sure it behaved appropriately before I ever posted anything here. 

This "testing" is in essence meaningless as most applications use the
operating system provided means to display all their text. Hence, they have
no control over the rendering of any font.

However, as POV-Ray needs to ray-trace fonts, it cannot use any font drawing
any operating system supplies. Consequently, it needs to read the font file,
and then extract all the information contained therein that "regular"
applications never even see because they just the the operating system to
draw the text.

> I've not seen anything slow about it or the other fonts I've had the problem 
> with,

The problem with the one specific font mentioned in this thread
(01-01-00.ttf) is rather simple. It contains a total of three tables
mapping* the characters' geometry (aka glyphs) to actual character numbers
(ASCII/Unicode). Two for Unicode, of which one is defective and does indeed
lack the characters as reported. Most likely (this is a guess) your
operating system deals with the problem by searching through all other
tables to find something usable - which not only is slow, but also should
*never* be necessary for a valid font file.

Due to these problems (the font file actually has other problems, such as
incorrect size specifications for some glyphs), POV-Ray cannot render your
font. The recommended solution would be to find a font repair/editing
program and have it read the font and then output it again. Most programs
for editing font should generate the missing data, or more likely actually
remove the unnecessary and broken first Unicode character mapping table.

	Thorsten, POV-Team

* For TrueType fonts, this table is commonly known as "cmap".

Post a reply to this message